REMARKS 



Reconsideration of the instant application is respectfully requested. The present 
amendment is submitted in conjunction with a Request for Continued Examination (RCE) 
and is responsive to the Office Action of February 21, 2008, in which claims 1-5 and 11- 
20 are presently pending. Of those, claims 1-4, 1 1-14, 16 and 18-20 remain rejected 
under 35 U.S.C. § 102(b) as being anticipated by U.S. Patent Publication 2002/0174218 of 
Dick, et al. In addition, claims 5, 15 and 17 remain rejected under 35 U.S.C. §103(a) as 
being unpatentable over Dick, in view of U.S. Patent Publication 2003/0233420 of Stark, 
et al. For the following reasons, however, it is respectfully submitted that the application is 
now in condition for allowance. 

In the present Office Action, the Examiner indicates that the arguments presented 
by the Applicants in the prior response of November 26, 2007 are not persuasive for the 
reasons that: (1) Dick's "application" header could purportedly be associated with the 
header of the SOAP application 208 in FIG. 2, and Dick's data extractor function 
purportedly builds/generates message/meta-data with semantic meanings to other message 
data; (2) the claimed SOAP message header/body attributes are purportedly "inherent" in 
a SOAP application, as reflected in the additional Scribner reference; and (3) that Dick 
purportedly teaches interpreting and processing the content of the message body 
associated with the message header, using the meta-data and semantics included in the 
message header itself, because Dick teaches the use of SOAP protocol and XML to allow 
programs to communicate with programs anywhere. 

In response, the Applicants direct the Examiner's attention to the following 
relevant portions of the specification, which discuss the differences between standard 
SOAP messages using static information/well known schema (i.e., inflexible data with no 
type information associated with the message) and flexible SOAP messages described 
using an XML schema using the 'any' construct (i.e., flexible data descriptions, but still 
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un-typed, therefore imposing a number of restrictions on existing message processing 
frameworks): 

"[0002] Most service oriented computer network systems use Simple Object 
Access Protocol (SOAP) as an encoding mechanism, and therefore Extensible Markup 
Language (XML) as the underlying message format. Normally, messages transferred 
between the client and the service and both parties follow a message format known to 
both of them such that they can determine the message type and map it to their type 
system. This determination is typically based on static information such a well-known 
schema (e.g., published by standard bodies), some previous agreement on the schema 
(e.g., published by the service provider in a service description such as WSDL), or using a 
standard set of application programming interfaces. There are also other cases wherein 
the XML schema information and types are embedded with the message, and the 
framework knows how to interpret the message. Such characteristics are acceptable for 
most of the presently utilized message exchange patterns where both the parties are 
familiar with one other and the message(s) exchanged therebetween." 

"[0003] On the other hand, it is also desirable to be able to support a message 
exchange pattern wherein both client and server are flexible such that messages may be 
sent without being bound to a previous agreement on the schema. Although "open- 
content" XML schemas are available by using the XML "any" type definition extension, 
there is still a semantic problem (i.e., meaning and use of the data) associated with flexible, 
open-content message data. This problem is driven by the static nature of the data and "a 
priori" agreements between both parties in the exchange pattern. Accordingly, it would be 
advantageous to be able to exchange semantic type information dynamically along with the 
message, but without disturbing the exchange pattern." 

None of the references of record teach or suggest solving the problem addressed 
by the present application, nor do they teach or suggest anything beyond conventional 
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SOAP message formatting, which is already discussed in the Applicants' specification by 
way of background. 

Notwithstanding, in the present amendment, independent claims 1 and 1 1 have 
been amended as set forth above to more particularly point out that the SOAP header 
includes "message meta-data and semantic type information describing at least a portion of 
the content of the SOAP message body so as to enable a receiver to interpret and process 
the content of the SOAP message body using the meta-data and semantic type information 
included in the SOAP message header, thereby facilitating a dynamic exchange of semantic 
type information and meta-data information for open content message exchange between a 
sender and the receiver." Support for the present amendment is found at least in 
paragraph [0013] of the specification. 

With regard to the § 102 rejections of independent claims 1 and 1 1, the Applicants 
again maintain that Dick fails to teach each element of the claims as presently worded. 
Applicants have in fact considered the references as a whole, and not just the cited 
passages. Assuming, for the sake of argument, that Dick's SOAP pluggable unraveler 208 
captures and processes SOAP headers, the data extractor 210 is described as capturing 
whether "two elements in the message have a semantic relationship" (paragraph [0037]). 
This is not the same as what is being claimed in the instant application, namely that the 
SOAP header includes message meta-data and semantic type information describing at 
least a portion of the content of the SOAP message body so as to enable a receiver to 
interpret and process the content of the SOAP message body using the meta-data and 
semantic type information included in the SOAP message header, thereby facilitating a 
dynamic exchange of semantic type information and meta-data information for open 
content message exchange between a sender and the receiver. 

Thus, even if Dick's data extractor is capable of building/generating message/meta- 
data with semantic meanings to other message data, it is still left to a service to handle the 
semantics. However, the service would need prior knowledge of the message in order to 
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properly process and parse the message, where the message is an un-typed (open content) 
format. This being the case, Dick does not disclose facilitating a dynamic exchange of 
semantic type information and meta-data information for open content message exchange 
between a sender and the receiver. 

Therefore, because Dick fails to teach each and every element of claims 1 and 11, 
the claims are not anticipated by Dick. As such, the Applicants respectfully submit that 
each of the applicable §102 rejections of the remaining claims have been overcome. 
Furthermore, since the Stark reference also fails to teach or suggest the missing claim 
elements described above, the §103 rejection of claims 5, 15 and 17 has also been 
overcome. 

For the above stated reasons, it is respectfully submitted that the present 
application is now in condition for allowance. No new matter has been entered. 
However, if any fees are due with respect to this Amendment, please charge them to 
Deposit Account No. 09-0463 maintained by Applicants' attorneys. 

Respectfully submitted, 
JOSHY JOSEPH, ET AL. 

CANTOR COLBURN LLP 
Applicants' Attorneys 

By /Sean F. Sullivan/ 

SeanF. Sullivan 
Registration No. 38,328 
Customer No. 46429 

Date: May 2 1,2008 

Address: 20 Church Street, 22 nd Floor, Hartford, CT 06 1 03 
Telephone: (860) 286-2929 
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